A business process typically comprises a set of tasks associated with executing an operation of a business. Such processes can be performed concurrently and continuously (e.g., making sales and collecting payments), or in sequence on a frequently recurring schedule (e.g., preparing paychecks).
A process calendar is commonly thought of as the schedule for a business process, and may present a timeline for the tasks involved in a process. The process calendar may be subject to constraints, such as, for example: due date of tasks (e.g., a specific date around which the tasks are scheduled); precedence of tasks (e.g., the relationship between tasks that specifies which tasks must be completed before or concurrent with other tasks); duration of tasks (e.g., the amount of time required to complete a task, which can be fixed or variable); volume (e.g., when inputs drive processing time, there is an upper threshold that cannot be exceeded and a lower threshold that should not be exceeded); elasticity (e.g., task duration that depends on the duration of other tasks (for example, management and quality assurance tasks may expand or contract based on other tasks)); time off (e.g., holidays and shut-down periods which decrease capacity); time on (e.g., overtime or part-time work which increase capacity); contention (e.g., there are not enough workers available to complete concurrent tasks); and shifts (e.g., the working hours schedulable for each task).
It is common for business processes to be outsourced. For example, a client may outsource its payroll process to a service provider, such that the service provider performs at least some of the tasks involved in the process. In such a situation, it is possible that both the client and provider may have tasks to perform in completing the payroll process. As a simplified example, the client may be responsible for reporting the time worked by each employee to the service provider, and the service provider may be responsible for timely payment of each employee.
Prior to outsourcing to a service provider, the client may have performed the business process on its own. For example, a company may have done its own payroll process for a time period before deciding to outsource the payroll process to a service provider. However, when transitioning to an outsourced process, there are usually differences between how the client performed the process and how the provider performs the process. That is, the client's custom process and the service provider's standard process may have significant differences due to technology, skills, best practices, etc. Furthermore, the client may engage third parties for some of its tasks, while the service provider may use subcontractors for some of its tasks.
Differences between the client's custom process and the service provider's standard process can lead to increased cost and complexity in performing the process. For example, the respective processes may differ in tasks, duration, timing, and staffing. More specifically, the client and service provider may use staff in different salary bands because their skill levels differ. For it to make sense for a client to outsource a process, the service provider's process needs to be less expensive and/or simpler than the client's current process, or produce better results. As the difference between possible options narrows, so does any perceived advantage to the client. Moreover, processes may also differ in anticipated service levels. If the client expects the service provider to attain higher service levels, the process may have to be altered.
Furthermore, when a client, service provider, third-party, and/or subcontractor have different constraints, the process manager may attempt to reconcile those differences in order to produce a feasible process calendar. For example, when parties are in different time zones and their shifts are not concurrent, time-zone differences are a constraint. Similarly, when parties have concurrent shifts but different holidays, time-off differences are a constraint.
Although the scheduling of tasks in a business process is similar to how tasks are scheduled in a project, business processes and projects are fundamentally different in several ways. For example, each project is unique in some way, but business processes are usually recurring. That is, a given task is normally scheduled just once per project, but perhaps multiple times per process (at least once per cycle). Also, projects are frequently late, while processes generally must be completed on time. That is, scope creep and change orders tend to make projects late, but service level agreements generally require service providers to complete process cycles on time or pay penalties, even when input volumes vary. Additionally, resources are typically assigned only for the duration of projects, but indefinitely to processes. The recurring nature of tasks in processes means each resource likely performs the same task over and over. Moreover, project schedules rarely, if ever, consider time zone differences, while processes often do.
Accordingly, there exists a need in the art to overcome the deficiencies and limitations described hereinabove.